回顧一下這系列文,從 Day 10 開始介紹如何在公司內組織 Data Team. 由於商業市場真是瞬息萬變,我想來聊一下何時要重新檢視 Data Team 架構是否還是不適合 🔄。
我剛成立 Data team 的時候就跟多數狀況一樣,因為只有 1~2 個人,也不用考慮地方分權,就只能中央集權 (參考 Day 10) ,滿容易在建立好 ETL 以及 BI 工具後就開啟服務模式。在 BI 工具的教學活動結束後,大家就會問我們說:哪你可以幫我建立 XX 圖表 📊?這樣我以後就不用每週都自己準備。
Data Team serves all teams
當我們開始處理這些需求、幫大家建立各種報表,就發現有很多類似的東西,我們產生了很多 data models 幾乎 80% 重複,可能多幾個或少幾個欄位! 😲 我們沒有投資時間去釐清整體需求,來一個打一個,也沒有討論好 data model 的設計。
一直到有個在營運團隊的成員,對資料處理滿有天份、也有興趣,在我們還沒有教學 BI 工具的時候,他就自己建立好給自己用的圖表。Data Team 成員跟他搭配合作很順,他對營運的了解對我們很有幫助。這個發現,讓我們開始想是否可以跟需求團隊搭配合作,一個在營運團隊對資料有興趣的人,搭配一個在資料團隊對那個領域有興趣的人,希望密切合作可以產生綜效 🚀。
🗝️ 成功要素:
DA pairing with data champion.
但也不是每個搭配都一樣成功。要看營運團隊那個人對資料的熟悉度,也要看資料團隊成員對那個領域的興趣程度,有人就會說:啊我就是對行銷沒興趣來做資料呀,不然我就去當行銷啦 🙃,也是有他的道理。
因為有成功搭配的經驗,讓我們開始更主動的分享分析結果,希望有不同的角度分析,帶來一點新鮮感可以引發討論。一開始可能很多人說好,但也沒空實際細看報告,不過長期堅持還是開始有點影響的 🌊。
深度合作到,有時候 DA 會懷疑他是否越線不只做 DA 的工作 😅 ,過程中確實會發生。只要合作過程是互相尊重、公開討論,互相補位是很重要的。
true collaboration
這種深度合作在人員有限的情況,不太可能跟每個團隊都做到這樣,但總是樹立了一個典範。
回顧時發現,改變不是刻意發生的,是因為一次偶然對了,想複製狀況,才去釐清成功要素跟架構。就算盡量複製了,也不一定保證下次應用在不同團隊就會成功 🌀。
每個資料團隊的成員,不只是主管,都可以回想一下組織合作方式的調整,做事方式、溝通方式、期待對方的行為等等,有哪些做法是可行或不可行。有時一個小地方的心態調整,就會產生滿大的影響。例如,當我們是中央集權的時候,先認清每個團隊的資料素養程度有差別,對於程度高的團隊,我們可以討論更深入的話題,程度低的團隊,我們該如何引導 🌱,光是「先認清每個團隊的程度會不同」,就已經影響我們後續的行為了。
在 Day 9, 我期待 Data Team 可以對商業價值有貢獻。下一篇我們就來回顧這個話題,以及是否有更具體的作法,敬請期待 🚀
對 dbt 或 data 有興趣 👋?歡迎加入 dbt community 到 #local-taipei 找我們,也有實體 Meetup 請到 dbt Taipei Meetup 報名參加